前言
昨天我們建立了修改日誌,記錄「改了什麼、為什麼改」。但日誌裡有一欄叫「驗證結果」,今天要深入處理的,正是這一欄背後的問題:你怎麼確定新版真的比舊版好,而不是自己主觀覺得「感覺比較順」?
這個問題,在一個人維護範本時特別容易被忽略——因為沒有人跟你對照比較,你很容易用「我覺得這樣比較好」取代真正客觀的驗證。今天要引入的 A/B Testing 概念,就是為了解決這個問題。

一、為什麼「憑感覺比較好」是不可靠的判斷方式
回顧 Day 5 建立品質檢查清單時提過的核心觀念:「好」如果沒有被拆解成具體、可檢查的標準,就只是一種主觀印象。 當你改了一版新的 prompt,如果只是把新舊兩份輸出擺在一起讀一遍,靠直覺說「這版比較好」,你其實正在犯 Day 5 一開始提醒過的錯誤——用模糊的形容詞做判斷,而不是用具體標準。
更麻煩的是,這種主觀判斷還容易受到當下心情、閱讀順序(先看哪一份會有心理錨定效應)、甚至只是單純看膩了舊版這些無關因素影響,不是真正反映「品質」的差異。
二、A/B Testing 的核心概念
A/B Testing 原本是產品或行銷領域常用的方法,核心邏輯很簡單:準備兩個版本(A 版與 B 版),用完全相同的輸入條件分別測試,再依照客觀標準,逐項比較兩者的表現差異。
套用到 Prompt 範本的場景,具體做法是:

1. 保留舊版 System Prompt(A 版)
2. 準備修改後的新版 System Prompt(B 版)
3. 用完全相同的一份測試資料,分別跑 A 版和 B 版
4. 依照 Day 5 的品質檢查清單,逐項對照兩份輸出的表現
   三、關鍵細節:「完全相同的輸入條件」不能馬虎
   A/B Testing 最容易失敗的地方,是測試條件沒有真正對齊。如果 A 版用了上週的資料,B 版卻用了這週的資料,兩者輸出的差異,可能只是因為資料本身不同,而不是 prompt 修改造成的——這樣的比較毫無意義。
   務必確保:兩次測試使用的是同一份原始資料、同一個時間點的 AI 工具狀態(如果工具本身有更新,結果也可能受影響)。唯一該改變的變數,只有 Prompt 本身。
   四、用 Day 5 的清單當評分表,逐項打勾
   比較時,不要只看整體印象,而是把品質檢查清單的每一項,拿出來對兩個版本分別評分。可以用一個簡單的表格記錄:
   檢查項目 A 版(舊) B 版(新)
   完整性:是否涵蓋所有必要章節 ✓ ✓
   完整性:是否所有事件都有被提及 ✗(漏了 1 筆) ✓
   準確性:內容是否都有資料依據 ✓ ✓
   格式一致性:標題與條列符號 ✓ ✓
   語氣風格:是否有 AI 味用語 ✗(出現 2 處) ✓
   這種逐項對照的方式,能讓你清楚看到:這次修改,具體改善了哪些項目、有沒有意外讓其他項目變差。 有時候修改一條規則解決了某個問題,卻不小心讓另一個原本正常的地方出狀況,只有逐項對照,才能及時發現這種「顧此失彼」的情況。
   五、什麼情況下不需要正式的 A/B Testing
   不是每次微小修改都需要跑完整流程。如果只是修正一個明顯的錯字、或補上一個原本漏掉的規則細節,直接測試新版、確認問題解決即可。A/B Testing 比較適合用在:修改幅度較大、或你不確定這次修改會不會影響到其他規則的情況——這時候正式比較新舊版本,能幫你確認修改的整體效益是正向的,而不只是解決了眼前那一個問題。
   六、今天的行動練習
   挑一次你之前做過、但沒有正式驗證過的修改,回頭用今天的方法,補做一次 A/B 對照測試:用同一份資料分別跑舊版跟新版,依照品質檢查清單逐項打勾比較,確認這次修改是否真的是全面性的改善。

小結
今天的核心心法,呼應了整個系列反覆強調的精神:判斷「好不好」,不能靠主觀感覺,要有客觀、可重複驗證的方法。 A/B Testing 把 Day 5 建立的品質檢查清單,從「寫出來的標準」變成「實際拿來比較評分的工具」,讓你的每一次修改,都建立在可驗證的證據上,而不是憑印象。
明天,我們要把「怎麼修改」這件事,收斂成一個具體的迭代心法——為什麼修改時應該針對單一問題局部調整,而不是一遇到問題就想整份重寫?